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SECTION 1 


INTRODUCTION 


The primary purpose of this specification 18 to provide an archi- 
tectural model which is the focal point for the evolution of GCOS 
8. It is not a deSign which can be achieved ina single release, 
but rather is a common goal which provides direction for the de- 
velopment and evolution of GCOS 8 products Such that they operate 
In a harmonious and consistent manner, 


Tne model presented supports the Distributed SyStem Architecture 
for a GCOS 8 System operating as a node-in a distributed networks 
as well as the multicomputer capabilities for local networks. 


ThiS architecture includes a high-level description of the system 
views or personalities presented to the end-user (@eGes 
timesharings batch, transaction processings administration). as 
well as the interactions between them. The accommodation of GCOS 
3 users and the miyration of these users to the native GCOS 8 en- 
vironment 1s also addressed. 


SECTION 2 


GOALS AND IMPLICATIONS 


In the process of arriving at an architectural model for Gcos 8. 
it became apparent that certain goals have a major impact on de- 
sign decisions. The following List includes those goals that 
most significantly Shape the architectural model. 


1.0 Support.of_the_ Ristributed Systems Architecture. (RSA 


Of all the goals» the support of DSA is the most pervasive. 
The DSA concepts of workstationss mailboxess and processes 
are used not only to define a distributed networks but are 
also the basic building blocks on which the GCOS 8 architec- 
ture rests. 


Two DSA concepts which forced major design decisions were: 
- Mailboxes are associated with workstations. 


- Mailboxes of a workstation are accessible to any 
process at that workstation. 


These two DSA conceptss together with a desire to protect 
one user from another tend to dictate a model for both 
timesharing and batch, Refer to section 5.2 and 5.3 for 
further explanation. 


One capability not addressed by DSA was found to be abso- 
Lutely essential to all of the architectural models consid- 
ered. AS commands arrive at aworkstations it becomes nec- 
essary to dynamically create and delete mailboxes and also 
to associate mailboxes with that existings executing 
workstation. This is true because the commands cause the 
execution of programs that utilize Session Control and, 
therefores require the use of specific mailboxes. 


2.0 Support Multicgmouter_Canability 


Multicomputer capability supports a collection of indepen- 
dents but tightly coupled computers that give the appearance 
of a single computer. The multiple computers form a local 
network that uses DSA interfaces for communication across a 
high speed Link Connecting the computers. 


The effect of this goal on the design is that certain system 
functions may be distributed in the local network and a Ses- 
sion Control interface 1s required for communication rather 
than the normal CALL interface. 


3-U Accommodate -GCOS_Il1l_Batche_T88Se2_IQSe2_and_QM-=IV_Usercs 


GCOS 8 must provide the capabilities to execute GCOS III 
programs in accommodation modes as well as to support GCOS 
III] JCL.e. The migration of users from these GCOS III envi- 
ronments to the native GCOS 8 environment must be as 
"“pnainless™ as possible. 


4-0 Supporctia—-Yoifecmo_Eowvicoomeot 


Although GCOS 8 does provide many different personalities or 
user views (e@.eges Timesharitngs Batchs, TPs Database Query, 
etc.) the great preponderance of GCOS 8 software is inde- 
pendent of the particular view being presented to a user. A 
minimal amount of Softwares usually only the command execu- 
tives should be dependent on a particular view. 


One implication of this. goal is that the batch = and 
timesharing environments become essentially identicals wit 
the exception of scheduling and priority. EOL anenlf 


time batch and tinesharing._sh ould use the same ‘< C (Dy ee 


Another implication of this goal is that ed softwar 
should be totally tndependent of the Location of the input , 
and output streams for a given user. A common interface jpyf 


will be provided that will accept input commands from either sus 
a terminals via Session Controls or a file. In the same way’ 
a common interface is used for output regardless of the des- 

tination. | 


Every effort will be made to provide a uniform environment 
across the various views Of the SyStem presented to the 
uUS@re 


SECTION 3 


DSA CONCEPTS 


(1) The fundamental architecture of distributed computerized 
workstations provides the programmer and end user the view 
of a logical network which is independent of the physical 
topology of the network of computers. 


The cornerstOne of the architecture 1s the workstation which 
is defined to be a location where some well defined set of 
functions 18 executed. A workstation is wholly contained 


within one computer. WwW BtIONS Naye.aS$0-64-3f.2.0 It Ateneo 


processess tenants, | mailboxes. _and~ “other. nade? SO MCL, CBee 
The topology of the set of interconnected workstations is 
the logical view of the network- the physical view is the 
manner in which the actual computers are interconnected, 


The programmer and end user see a network of workstations 
interconnected by logical connections which are created and 
destroyed dynamically as needed. (See figure 3=-2.a.) The 
end user in the form of a terminal Operator may request some 
work to be done which requires the cooperation of several 
werkstations (for instance the update of Several databases 
which are in different locations). To do this work the end 
user 1S represented tin each ane of these cooperating 
workstations by a datastructure called a tenant. The tenant 
structures act as agents for the end users they contain the 
minimum amount of information which needs to be kept at all 
time for this end user. 


The tenants must exchange information among themselves in 
order to execute the end user work. This 1s done by 
exchanging message records via sessions which are logical 
paths connecting two tenants. (See figure 3-2.b.). 


Workstations have ONe or more associated mailboxes, The 
mailbox 15 the. mechanism by which a workstation is 
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(1) This section is included verbatim from: 
GCQOS_83_Distcibuted_Database_Access- Georges Colliat 
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addressec. Logical connections actually connect two 
mailboxes and may Contain several sessions between different 
tenants of the two workstations. 


workstation tenant tenant 


session 
Logical 
connection 
tenant 
terminal 
network of workstations network of tenants 
interconnected by logical connections located in workstations 
figure 3-2.a 4 figure 3-2.eb 
tenant 
mailbox 
sessions which use identical Workstations are addre: 
protocols may share the same via their mailboxes, | 
Logical connection connections are betwee 


mailboxes. 


figure 3-2.¢ figure 3-2ed 


In order for a tenant to do some work it must be associated 
with a procesSs which 118 the basic entity allocated to a 
processor by the operating system. The structures which 
compose a process are quite large », 16,000 bytes or more. 


If a very large number of end USES are CONN PELE... nb Qmobf€ 


‘Pei etatnenAL. DNASE Clration of ” aay? 
2 stem: the association | ww 8 PLOCESS tO each tenant 
ae 2 ing the « end user—weu wourtd—pequice _™3 orohibitive amount 


‘o f aa resources. But if one notices that in many envi- 

ronments, the amount of processing done by a tenant is neg- 

ligible compared to the idle time of that tenant and if in 

addition we notice that during this idle time very Little 

information needs to be retained for the tenants then it be- 
“\ comes natural to associate a process to a tenant only during’. 
‘process.ing—timre—or—uben a Large amount of intormation needs 
‘to be retained re idle time. This phenomenon is called 
MAPPING and UNMAPPING a tenant to aprocess. A workstation 
can be created with a certain number of identical processess 
which are mapped successively to tenants in a much larger 
number (ratio in the order of 1 to 1000). The UNMAPPING re- 
quires that the useful size of a tenant has shrunk to a 
small minimume This 1s not possible for all type of appli- 
cations andas aresult this facility is not necessarily 
useful for all types of workstations. Only certain type of 
workstations have the unmapping option. 


Different workstations exist to perform different types of 
works i.e. each workstation may be tailored according to the 
type of work it performs. This tailoring is done by the 
main procedure which 1s shared by all the processes at the 
workstations it 1s called the Command Executive. The com- 
mand executive is the first procedure in control when a 
process starts and the last procedure in control when the 
process terminates, in case of faults or exceptions it 15 
also the procedure which gets control. As a result the com- 
mand executive has full control over the life of the 
processes of the workstation thus giving its personality to 
the workstation, 


SECTION 4 


A CONCEPTUAL MODEL OF GCOS 8 


A conceptual model of GCOS 8&8 must include two dimensions: 


~ a topological view of the organization of system 
servicess and 


- a functional view of the system organization 


1.0 GCOS. 8_Tovological._Mogel 


The software organization of GCOS 8 1s represented in figure 
4-1. %Although more layers can be identifieds for simplicity 
the system Can be viewed as composed of three Layers or con-. 
centric circles. 
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Figure 4-1 Organization of GCOS 8 Software 


1-1 Kercnal 


The innermost layer is known as the Kernal and is that group 
of operating system procedures that provide the most primi- 
tive services. These procedures are extremely dependent on 
the idiosynchrocies of the hardware and typically execute in 
privileged master mode. Examples of Kernal procedures ares: 

- 1/0 drivers and channel modules 

- Interrupt handling 

- process dispatching 

- memory paging 


1.2 System-Shaced.Softwace 


The next layer is the System Shafed Software. This layer 
provides a cOmmon base on which the outermost shell rests. 
It is the Shared Software that provides the functions Common 
to all users regardless of the view or personality of the 
system that is being utilized. The System Shared procedures 
execute in slave mode. Examples of System Shared procedures 
include: 

- data base management 

- buffer management 

- session control 

- file system 

-~ concurrency control 

- workstation Management 


1.35 System_PecsQonality 


The outermost layer is composed of a number of views avail- 
able to the end-user. Examples includes 


- batch 

- timesharing 

- transaction processing 
- database SuBey 


- administration aids 


- distributed maintenance 


One user may be running batch programs at the same time an- 
other user 1s interactively issuing querieS to a database. 
The “system” as seen by these two users is radically differ- 
ent and yet these various views or personalities of the sys- 
tem all rest upon the common services provided by the System 
Shared Software. 


2-0 Evoctigoal_Madel 


The most basic model of GCOS 8 iS ShoWn in Py ure 4- as It 
eee sa theese kinds of workstationss a ° 


Le Manager WOLrns tat Los qne or more 
aces eanaenes and a_potentially large number of Appli 


WorkstationSe | 


The GCOS 8 Operating System executes on a Level 66/DPS-8/ADP 
Information Processor that is an element of a DSA network. 
The GCOS 8 System may control a single computers as in 
today's machiness or a multicomputer complex. The 
multicomputer complex is a collection of independents but 
tightly coupled processorsse connected by a high’ speed 
inter-computer links, that form a single computing resource. 


Whether a single computer oor a OIE fan the 
GCOS. 8 System contains a sing le WOCKS. on which is the 
Control point. for all EBSOULCES _ nd all processing. 
activities. This scheduler= ernie Manager  CSRM). 


Workstation schedules batch ~ Jobs and activitieS»s reserves 

resources On behalf of processes and workstationss, and per- 

forms load leveling functions across the computers’ of the 

multicomputer complex. The SRM Workstation is also the one 

to which end-users initially log-on. The SRM Workstation is 
then responsible for determining which Application 

Workstation at the computer complex will be used to process 
the user*’s work. If a suitable Application Workstation is 
not available, the SRM Workstation may create a new Applica- 
tion Workstation for this user. Since the workstation being 
created may not be in the same computer as the SRM 
Workstati1On, SRM communicates with an Initializer 
Workstation in the proper computer which will create the Ap- 
plication Workstation, 


The initializer Workstationss ¢ one pe Per GOMRU TEL + create and 
terminate ApplicatTon workstations on On the command of the SRM 
Workstation. 


Application Workstations come in many different forms and 
provide a variety of facilities: batch input» system output, 
file transfers timesharings transaction processings etc. A 
common characteristic of all Application Workstations is 
that they are created and terminated dynamically by the 
Initializer Workstation on command of the SRM Workstation. 


Application Workstations may have one or many occurrences, 
For some workstations such as ITPs many users are handled by 
a single occurence of the workstation. The ITP command ex- 
ecutive maps or associates the tenants with one of the 
orocesses at the ITP Workstation only when a tenant has work 
to perform such aS when a transaction arrives. ThuSs many 
end-users are handled by a single ITP Workstations, though 
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several ITP Workstations may be executing concurrently for 
different transaction processing applications. 


Other Aoplication Workstations, such as batch and 
7 timesharings have many occurrences. Each batch activity and 
‘leach timesharing user is allocated a single tenants, single 
SJrocess workstation to pertorn "NTS wore. “Ths process is 
dedicated to the tenant for the lif of the activity or 
timesharing session, A single workstatiOn per user permits 
programs executed at the workstation to use Session Control 
to correspond with other workstations without interfering 
with sessions for other users. See section 2ele 
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Figure 4-2 Overview of GCOS 8 System 


SECTION 5 


USAGE SCENARIOS 


veh 
ee 


1.0 eckstation-Refioitions-Creatione and Lecmination” 


Workstaions are defined by SSystép Administrator and the 
* A i. ° a . ° ° e 
definitions are recorded in a Workstatio De fin on 
Database, To accomplish thiss GCOS 8 provides an Adminis=- 
trator Work lon——which acceptS commands which both de- 
scribe and control the state of workstations. This is shown 


in figure 5-1. 


The System Administrators at a terminals logs on by 


establishing a session with the SRM Workstation. The SRM 
Workstation validates his use of an Administration 
Workstation and then selects a particular Administration 


Workstation if more than one are active. If no Administra- 
tion Workstations are actives SRM may enable one by calling 
on the Initializer Workstation. The mailbox of the Adminis- 
tration Workstation is returned to the user and the log-on 
session 1s terminated. 


ey 
‘ae The user (Cor terminal controtter)._t-hea—establishes-a—session —- 
\e with the Admintstration Workstation through which he has 
comp —Gttess to the workstatror Definition Database. 


Commands at the Administrator Workstation fall into two 
broad categories; 


- those that creates modify» and delete entities on 
the Workstation Definition Database (e.ges 
workstationss mailboxesse etce)s and 


- those that control the state of workstations 


Thuss the administrator can define a workstation and then 
make it operational by entering an ENABLE workstation com- 
mand. ThiS command causes the Administrator Workstation to 
establish a session with the Scheduler-Resource Manager 
(SRM) Workstation to request the enabling of the input Ap-. 
plication Workstation. 


The SRM Workstation selects a computer (Cif a multicomputer 
complex)s reserves the resources requireds and issues a com- 
mand to the Initializer Workstation to activate or enable 
the Application Workstation. The Initializer Workstation 
retrieves the workstation definition from the datahase and 
creates the desired workstation along with the processes and 
mailboxes defined for the workstation. 


Commands are also available to the administrator to termi- 
Nate and abort workstations. 


As users lLog-on to the systems the SRM Workstation may also 
automatically cause workstations to be created as required. 
However before a workstation can be enabled in this fashion, 
the administrator must set the "automatic enable” attribute 
for that workstation. 


l { { { 
| TERMINAL lo: eb wee ees TERMINAL | 


| I | CONTROLLER | i 
~---+------ | WORKSTATION | | log-on 
lalate tedneneteetaaten f session 
; i 
l | 
i | 
| | | | 
| ADMIN. | | SCHEDULER | 
WORKSTATION I oT | RESOURCE i 
{ | MANAGEMENT { 
a ieeieteetatceieniettatetaaton | WORKSTATION I 
| | 
Workstation { 
Definition | 
Database | 
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WORKSTATION 


APPLICATION 
WORKSTATION 


Figure 5-1 Workstation Administration 


2-0 TIMESHARING-Scenaria 


Each timesharing user 1S represented in a GCOS 8 System by a 
single tenants single process workstation. This design is 
required to support the execution of programs which use Ses- 
s1on Control under the purview of the Timesharing 
Workstation. One of the implications of this approach is 
that mapping/unmapping of tenants onto processes is not ap- 
plicable to timesharing. Multiplexing of tenants Onto 
processes is only viable when the structure required to de-~ 
Scribe a tenant is small when compared with the size of the 
process structure. Since this is not true in the 
timesharing environments a process for each tenants, or 
timesharing users 1S required, 


When a terminal user wishes to use the Native timesharing 
facility of GCOS 8s a session is initiated from the terminal 
controller to the SRM Workstation. See figure S-2. The SRM 
Workstation Performs the initial lLog-on functions, validating 
the use of the timesharing facility by this user at this 
complex. 


Upon successful Completion of the‘ log-on sequences the SRM 
Workstation sends a message to the Initializer Workstation 
which creates a new occurrence. of the single processes 


 .Timesharing Workstation. Each Timesharing user does not re- 


quire a separate workstation definitions rather a TSS 
Workstation definition prototype is used to create all the 
TSS Workstations. 


The user may have specified an initial mailbox name as part 
of the tlog-on sequence. If sos that mailbox is associated 
with the created TimeSharing Workstation.e If no mailbox 
name was specifieds a mailbox is dynamically assigned to the 


.Jaimesharing Workstation. 


The SRM Workstation sends the name of the mailbox for the 
new Timesharing Workstation to the user and terminates the 


‘ a session with the Terminal Controller Workstation, 


og C The user (Cor the terminal controller) establishes a new ses- 
“=—@€ Sion with the newly created Timesharing Workstation via the 
L.tcreated Mailbox. The Timesharing Workstation validates the 


user and control is passed to the native timesharing command 
executive. The command executive 1S implemented as system 
shared procedures but is executed under each Timesharing 
Workstation. 


ci ‘The user may wish to execute programs that use Session Con- 


pack 


‘ trol to communicate with other workstations. The mailboxes 


ireferenced by these programs need to be dynamically assigned 
to the user's Timesharing Workstation. The user should have 
full control over the uSe of mailboxess just as he does for 
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files. The TSS Command Executive should implement commands 
that manipulate mailboxes: create mailbox, delete mailbox, 
assign mailbox to workstations etc. 


Most timesharing commands will be executed by the process at 
the user's Timesharing WorkStation. Howevers some commands 
may require a different computer of the multicomputer com- 
plex. For example, SUnPOS* one computer was pene tee: as 
Ithe "COBOL machine”, | [oY OW oi Woe ea 
[this—ene—computels When the timeSharing user enters a COBOL 
/Compilation Comman the Timesharing Workstation establishes 
\a session with a COBOL Workstation that is tlocated in the 
\COBOL computer and the command its sent to the COBOL 
iWorkstation to execute. The COBOL Workstation 1s able to 
i | communicate with the terminal user via. the Timesharing 

|Workstation. When the compilation 1s completes the session 
WP [Between the Timesharing and COBOL Workstations is 


\terminated. 
oe . 


When the session between the user and the Timeshafring 
Workstation is terminated via a loOg-off command or a line 
disconnects the Timesharing Workstation notifies the 
Initializer Workstation and the Timesharing Workstation is 
terminated. 


Figure 5-2 
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3.90 BAICH. Scenario 


The scenario for native batch execution is precisely the 
Same as that for timesharing. The same JCL is used for each 
ands probably» the same Command executive is used for both 
environments. 


The only significant difference between native batch and 
timesharing is that batch jobs are entered into the system 
as a complete unit and are sceduled for executions whereas 
the timesharing user enters commands interactively from a 
terminal. 


Each Geebwity—ot—e) batch Job is executed as a single tenant, 

Single process workstation. This design supports” the 
activity's use of Session Control for the purpose of commu- 
Nication either with other workstations or with the terminal 
user. 


The batch job may originate from a local device such as a 
card reader, from a remote Location in the networks, or as a 
result of a spawn job cOmmand in another workstations such 
as Timesharings See figure 5-3. | 


If the job originates at aremote terminals, the Terminal 

Controller Workstation establishes a session with the Batch 

yp’ %Input Workstation in the destination information processor 

adh, Ce.ges GCOS 8 host). . tc .tInput Workstation exists per 

1? comput er complex. The jaaut job is then transmitted as 
peer series of messages. 


The Input Device Control Workstations are types of terminal 
fcontrollers which accept a local input job stream and con- 

\ f vert the data from the external media (cards» taper etc.) to 
Nu. £ a. series of messages that are relayed to the Batch Input 
“Workstation. Conceptually, there is no difference between 

| local - and remote job entry. An Input Device Control 


Workstation is re require: DAY He. Ene SSCL LAR A 


: Fere (som > Batch Thor Workstation. 
The “Batch Input ‘Workstation uses a common access method: 
interface to read the input Jobs. Depending on the device 
type and locations the access method will use Session Con- 
trol for a remote device or ee use IQS Poe a local device. 
Jobs spawned ee ie ceiwhee tides. eoik as TSS> are 
sent to the Batch Input Workstation just as if they were in- 
put via a terminal controller. 


As it receives a stream of jobss the Batch Input Workstation 
performs an operator validation function and then creates a 
command file for each job of the job stream. Then for each 
jobs the Batch Input Workstation scans the JCL and deter- 
mines the resource requirements for the job as a wholes as 
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well as for each activity. A message is then Sent to the 
SRM Workstation signalling the presence of the jobs its com- 
mand file nam@s, user-ids and resource requirements. An al- 
yeahs design is one in which the SRM workstation per 
forms the—funetions of the Batch Input Workstationas— 


Pp ther = eUCiminating it. The relative merits of each design 
f have not been closely examined. 


The SRM Workstation validates the user-id and enters the job 
into one of the job queueS. Based on resource availability, 
the SRM Workstation reserves resources’ for yobs and 
activities, CHEN = SON Sewer 2 SS to an Initializer 


WOrksStation to start the job. See figure 


“syn 5 a ee 


The Initializer Workstation retrieves information about the 
job from the message received from the SRM Workstation 
and/or from the command file. It then allocates the re- 
sources which were reserved by the SRM Workstation. This 
resource allocatiOn involves the creation of system tables 
Ce.ger the PAT Segment), whereas the resource reservation 
performed oT eS 
concurrency control tables. The . Initializer Workstation 
then—creates a single tenants single process workstation for 
the activity... This Activity workstation is created from a 
; batch@rotatype workstation reertteres. If a mailbox name 
specified for the activity in the JCL» that mailbox is 
associated with the created workstation. If none was 
specifieds a mailbox is dynamically assigned to the 
workstation. 


; 
The Aettvity Workstation is then started and the batch ac- 
tivity is executed. The Batch Activity can call on any of 
the shared system servicess including Session Control. This 
permits the job to Communicate with other workstations such 
as -timesharing. At the termination of the activitys the 
BeOS ca DOR ee or ee et es rere 
de Calternativelys the process and workstation could 

weaved. tor a different activity). ~ 

| get ORRIN CRR yy epi ee 
job follow Same procedure 
acme fice se cdats process» 

— started by the Initializer 

that must be carried across 

job*s command file, 


Subsequent activites of the 
(1.@ee 
and Workstation 
Workstation). :°= A 
activities o he job is recorded, 


At the conclusion of the jObs the SRM Workstation signals 
the System Output Workstation to process the system output 
files for the job, See figure 5-5, The System Output 
Workstations one per computer complex» converts the output 
from the file into a stream of messages that are relayed to 
a Terminal Controller Workstation for remote output or to an 
Output Device Control Workstation for local output. The 
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Output Oevice Control workstation operates asa terminal 
controllers, but handles on-line devices such as’ line and 
page printerse As with the Input Device Control 
Workstations the Output Device Control Workstation is only 
required if the local devices are in a different computer 
from the System Output Workstation. 


An alternative design is one in which the SRM Workstation 
assumes most of the functions) of the System Output 
Workstation and interfaces directly with the Output Device 
Control Workstations. More design is needed before a proper 
evaluation of these two choices is possible. 
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Figure 5-4 Batch Execution 
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4.0 INTEGRATED TRANSACTION PROCESSING Scenario 


An ITP Workstation 1s capable of supporting multiple 
processes and a large Number of tenants. The ITP command 
executive maps a tenant to a process only when that tenant 
has work to dos such as when a transaction arrives. 


As with timesharings the ITP user first LOgs on by 
establishing a session with the Scheduler-R@source Manager 
(SRM) Workstation. See figure 5-6. The SRM Workstation 
validates the user and sends the mailbox name of the. ITP 
Workstation to the user. The user (or the terminal control- 
ler) terminates the session with the SRM Workstation and 
establishes a session with the ITP Workstation. 


If the SRM Workstation discovers that the desired ITP 
Workstation 1S not presents it may direct the Initializer 
Workstation to start the ITP Workstation if the “automatic 
enable” attribute is set on the workstation definition. See 
section 5.1. 


Figure 5-6 
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SECTION 6 


ACCOMMODATION AND MIGRATION 


By virtue of the consistent architectures the shared system 
software that supports functions of native workstations also 
supports accommodation workstations. The great majority of 
the shared software is totally independent of the type of 
workstation from which it is called, including whether na- 
tive or accommodation. 


GCOS’ III programs are accommodated on GCOS~7 8 through two 
different mechanisms: MME accommodation and run-time support 
routines. 


(Programs in system loadable formats Such as H**ss» and GMAP 
“programs afe accommodated by trapping the system calls 
{(MME*%s) and converting them from the MME interface into the 
|native system interface. Mosts though not all» MME*s are 
\accommodated in this fashion. 


The run-time support routines are a layer of code that ex- 
ists between the compiled program and the native system 
software, A run-time package will be provided’ for each 
Higher Order Language compilers both native and accommoda- 
tions to convert the system callS generated by the compiler 
INtO native System calls. 


Thus a user who is willing to relink his programs will be 
bound with a GCOS 8 run-time environment which calls = on 
shared software (Ce.egese UFAS and IDS), whereaSs aouser who 
executes an H* is already bound with the GCOS III UFAS or 
IDS ands therefores can be accommodated only at the MME lev- 
el. This of course implies that any new functionality 
provided by the GCOS 8 shared UFAS and IDS will only be 
available to users who relink their programs. 


1.0 Agcommodgatioon.Barch 


Existing batch jobs are executed in a similar manner to na- 
tive batch programs. That iss the flow ob batch inputs exe- 
cutions and output is the same as that described in section 


6-1 


Sele The primary difference between native batch and accom- 


modation batch is the JCi. JhisS implies a different command. 


executive for each ands thereforese a different Application 
OR rm Oe e eT peacoat eae e ry wer " 

Wo Ne AS with native batch, each activity of an ac- 

commodation job will execute in a separate single tenant» 


single process Accommodation Batch Workstation, 


Accommodation jobs that use communication features 
CGEROUT/DONET) must be bound with a new run-time environment 
that uses Session Control interfaces. GMAP programs must be 
converted to use Session Control before execution. All oth- 
er system calls (MME's) are trapped and converted to calls 
to the native shared procedures. 


2.0 Acconmodatioo_lJimesbariog 


Accommodation timesharing users are serviced by an Acco™mo- 
dation Timesharing Workstation which is a multi-tenants sin- 
gle process workstation that functions similarly to its GCOS 
3 counterpart. 


A native timesharing user is able to spawn batch jobs which 
are executed at an Activity Workstation for native mode 
prgrams or an Accommodation Batch Workstation for accommoda- 
tion mode programs. Howevers, this user will also wish to 
execute GCOS III programs (Cx and H*) from his native 
timesharing workstations rather than Spawn a batch job. 
Many accommodation programs should run quite easily at a na~ 
tive workstation. Other programss howevers may have to exe-~ 
cute at an accommodation workstation due to dependencies on 


the Gcos III environments such as fault processing 
facilities. This quiestion requires a great deal more 
Study. . 


3.0 AccQmmadation_Icansactiogn Processing 


An Accommodation OM-IV TP Workstation is provided for 
servicing DOM-IV TP users. Like the Accommodation 
Timesharings this workstation is also a multi-tenant, Single 
process workstation. 


